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Summary 

Language  enhancements  carried  out  for  the  ESPRIT  ‘SPRITE’  project  2260  are  dis¬ 
cussed.  These  enhancements  include  naming  of  output  signals,  multiple  identifier 
declarations,  multiple  instantiation  of  functions  and  advanced  connectivity  of  cir¬ 
cuits.  A  new  primitive  has  also  been  added  to  the  language  for  extending  the  timing 
model.  The  syntactic  and  semantic  definitions  of  the  enhancements  together  with 
examples  of  text  are  presented. 
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1  Introduction 

This  document  outlines  language  enhancements  to  the  Hardware  Description  Language 
ELLArA*  that  have  been  carried  out  for  the  ESPRIT  project  ‘SPRITE’.  The  ELLA  lan¬ 
guage  was  chosen  at  the  commencement  of  the  project  alongside  Silage  [2]  as  an  input 
language  to  the  Cathedral  Silicon  Compilers  [1],  ELLA  was  chosen  for  the  project  because 
its  semantics,  particularly  its  applicative  style,  are  well  matched  to  signal  processing  tasks 
and  because  it  has  a  well  developed  support  environment.  However  in  order  to  fulfil  all 
the  functions  required  of  the  SPRITE  design  language  it  was  recognised  that  a  number 
of  enhancements  to  the  language  were  required.  It  is  these  enhancements  that  will  be 
described  in  this  document. 

The  enhancements  include  the  ability  to  name  function  output  signals  and  their  sub¬ 
sequent  ‘joining’  within  the  function  body,  the  instantiating  of  multi- dimensional  rows  of 
functions  with  greater  flexibility  in  their  external  connection.  The  other  major  enhance¬ 
ment  to  ELLA  has  been  in  the  introduction  of  timescaled  regions.  These  are  regions  which 
have  internal  clocks  running  either  faster  or  slower  than  the  enclosing  function.  This  en¬ 
hancement  was  implemented  so  that  ELLA  can  have  the  ability  to  model  the  functionality 
of  Silage  Interpolate  and  Decimate  functions. 

All  the  features  described  in  this  document  are  available  in  the  current  release  of  the 
SPRITE-ELLA  system. 

The  language  enhancements  will  be  introduced  in  turn  with  their  collective  syntax 
given  in  appendices. 

2  Multiple  Declarations 

Previous  versions  of  ELLA  (see  [3])  have  only  supported  single  identifier  declarations 

e.g. 


LET  a  *  FUN C( input  1,  input2). 


Enhancements  to  the  language  now  permit  multiple  identifier  declarations  in  the  left  hand 
side  of  such  expressions,  for  example 


LET  (al,a2)  *  TWO.OUT_FUNC(inputl ,  input2). 


In  ELLA  sequence  clauses  VAR’s  and  PVAR’s  have  been  enhanced  to  allow  similar  formats, 
and  sequential  assignment  statements  enhanced  to  allow  the  following 


(al,  a2)  :«  <bl.  b2); 
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Each  of  these  declarations  will  now  be  considered  with  a  complete  definition  of  the  syntax 
given  in  appendix  A. 

2.1  LET  Declarations 

Multiple  declarations  allow  collaterals  of  identifiers  to  be  grouped  together,  thus  giving 
users  the  ability  to  assign  different  names  to  different  parts  of  a  ‘unit’  clause,  (see  [3]  for 
description  of  ELLA  units),  for  example 

LET  (al,a2)  ■  TWQ_OUT_FUEC(inputl,  input2). 

where  TWO.OUTJFUNC  is  a  function  which  has  two  output  signals.  The  number  of  iden¬ 
tifiers  declared  in  such  statements  must  equal  the  number  of  signals  of  the  value  delivering 
(unit)  clause. 

Such  declarations  can  also  help  to  ‘tidy  up’  series  of  LET  statements.  For  example 
with  multiple  LET’s  such  a  set  of  statements  as 

LET  a  *  d,  b  «  a,  c  ■  f. 


can  be  written  as 


LET  (a.b.c)  =  (d.e.l). 

Multiple  LET’s  can  also  be  used  to  simplify  ELLA  text,  for  example 

LET  dummy  ■  CASE  (inl,in2) 

OF  (t.t): 

(l.bool) l(bool.l):  tt.t.f) 

ESAC. 

LET  a  =  dummy  Cl],  b  *  dummy [2],  c  =  dummy  [3]. 


can  now  be  written  as 


LET  (a,b,c)  *  CASE  (inl,in2) 

OF  (t.t):  (t.l.t), 

(1 ,bool) | (bool.f ) :  (f.t.f) 

ESAC. 


In  certain  cases  it  may  not  be  required,  or  desirable,  to  name  till  the  outputs  of  a  ‘unit’ 
clause.  In  this  case  null  names  may  be  used,  however  there  must  be  at  least  one  non-null 
name,  thus 
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is  valid  but 


LET  (  ,a,  )  =  (ini,  in2,  in3). 

LET  (  ,  ,  )  *  (ini,  in2,  in3). 


#  legal  * 

«  illegal  * 


is  not. 

A  restriction  imposed  on  multiple  LET'S  is  that  they  can't  be  used  to  decompose  a 
STRING  (a  STRING  is  a  special  form  of  packed  array  possessing  the  global  unknown 
property,  see  [ll]).  For  example  the  following  is  not  allowed 


LET  (a,  b,  c)  ■  STRING  [3]  bit’O.  #  illegal  # 

Multiple  LETs  can  also  be  used  in  the  ELLA  sequence  clause  and  they  follow  the  iden 
tical  rules  as  in  the  functional  part. 


2.2  Variable  Declarations 

Variable  assignment  declarations  are  used  solely  in  the  ELLA  sequence  clause  and  the 
introduction  of  assignment  variables  occurs  through  either  a  VAR  or  PVAR  statement. 
These  statements  are  enhanced  in  the  same  way  as  LET  statements  such  that  the  following 
are  all  legal  statements 

VAR  (a,b,c)  :=  (t,f,x), 

(u,v,w)  :=  (t,  i/2,  char’c); 


PVAR  (on®,  two,  thr®®) 
(unknown,  value) 


(i/1,  t,  char’z), 
(?bool,  i/2); 


In  multiple  VAR  and  PVAR  assignments,  as  with  LET  statements,  some  but  not  all  of  the 
expected  names  may  be  null,  for  example 


VAR  (a,  ) 
PVAR  (on®,  ,  ) 


:=  (i/2,  t); 

[3]  char ’k; 


#  legal  # 
«  legal  « 


VAR  (  ,  ) 
PVAR  (  ,  ,  ) 


:■  (i/2,  t); 

[3]char’k; 


#  illegal  # 

#  illegal  # 
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2.3  Assignment  Statements 

Once  a  variable  has  been  declared  through  a  VAR  or  PVAR  declaration  it  can  be 
assigned  to  via  an  assignment  statement.  Like  the  variable  declarations  the  assignment 
statement  has  been  extended  to  allow  collaterals  of  variables  on  the  left  hand  side,  for 
example 


(on*,  two,  thr**)  :■  (a,b,c); 

(  ,  valu*,  )  :■  (u,  v,  w); 

(array [2. .3]  [[in]] ,  row[3],  valu*)  :«  ( input 1 .input 2, input 3) ; 

As  with  declarations,  multiple  assignments  can  have  some  but  not  all  of  the  expected 
names  given  as  null,  for  example 


(  .  .  a.  )  :-  FOUR. OUT. FUSC (input);  #  l*gal  # 
(...)  :*  FOUR.OUT.FUBC(input);  #  illegal  # 

where  FOUR.OUT-FUNC  is  a  function  that  delivers  four  output  signals. 

A  further  restriction  which  is  placed  on  multiple  assignments  is  that  the  same  identifier 
cannot  appear  more  than  once  in  the  left  hand  side.  This  is  because  multiple  sequential 
assignment  statements  are  treated  as  parallel  statements  within  a  sequence  step.  Thus 
there  is  no  specified  ordering  of  execution,  and  hence  potentially  ambiguous  statements 
must  not  be  allowed,  for  example 


(a,  b,  c,  d)  ;=  (in,  a,  a,  b);  #  l*gal  # 

(array [2. .4] ,  b,  c,  array)  :*  FOUR. 0UT_FUBC( input ) ;  #  illegal  # 


However  a  statement  of  the  form 

(a,  b)  :=  (b,  a)  #  l*gal  # 

is  allowed  and  this  swaps  the  contents  of  variables  ‘a’  and  ‘b’. 

3  Named  Outputs 

ELLA  V4  only  allowed  functions  with  unnamed  outputs,  this  meant  that  the  output  of 
a  function  could  only  be  given  through  an  OUTPUT  statement.  An  enhancement  carried 
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out  foi  the  SPRITE  project  allows  the  naming  of  outputs  and  their  joining  within  the 
function  body. 

The  format  for  an  output  type  is  similar  to  an  input  type,  for  example 
FN  A  *.(typ*:in)  ->  (typ«:out):  ... 

Of  course  unnamed  outputs  are  still  allowed  in  exactly  the  same  format  as  before  (see  [3]). 

By  providing  named  outputs  the  user  also  has  the  choice  of  how  the  output  may  be 
joined,  for  example 


FH  A  =  (type: in)  ~>  (type: out): 

(  ... 

JOIH  in  ->  out. 

). 


FH  A  =  (type: in)  ->  (type: out): 

(  ... 

OUTPUT  in 

). 


These  two  examples  show  the  only  ways  in  which  the  output  can  be  joined.  Thus  an  output 
must  be  joined  to  by  either  an  ‘OUTPUT’  statement  or  specific  ‘JOIN’  statements.  There 
can  never  be  a  mixture  of  part  of  an  output  signed  being  ‘joined’  by  the  OUTPUT  statement 
and  the  rest  by  explicit  JOIN’S. 

4  Enhancements  to  the  Function  Type  Mechanism 

Before  continuing  with  the  enhancements  carried  out  for  SPRITE  an  enhancement 
carried  out  for  a  UK  IED  (Information  Engineering  Directorate)  project  will  be  described. 
This  enhancement  is  incorporated  into  the  SPRITE-ELLA  system  since  it  is  anticipated 
that  it  could  provide  extra  functionality  advantageous  to  transformational  design.  Only  a 
brief  overview  will  be  given  here,  a  complete  account  is  provided  in  [10]. 

Function  types  in  ELLA  are  an  enhancement  of  the  basic  type  mechanism  and  are  used 
for  defining  signals  that  carry  information  in  both  directions.  Before  these  enhancements 
function  type  signals  were  used  in  a  limited  way,  as  input  signals  to  a  function  but  never 
as  output  signals  and  hence  function  types  required  the  use  of  function  sets,  which  are  an 
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extension  to  the  ELLA  function  mechanism,  in  order  to  communicate.  However  it  is  now 
possible  to  have  function  types  delivered  as  outputs,  both  in  function  specifications  and 
value  delivering  clauses. 

The  definition  of  a  function  type  has  not  changed  and  therefore  a  valid  function  type 
definition  is 


TYPE  enuml  «  HEW  (vail  I  val2  I  val3  ), 
•num2  *  NEW  (resl  I  r«s2  |  r«s3  ), 
enuml _to_enum2  *  enuml  ->  enum2. 


where  ‘enuml.to-enum2’  is  a  function  type  that  has  a  signal  ‘enuml’  in  or.e  direction  and 
a  signal  ‘enum2’  in  the  other. 

An  example  of  a  function  with  a  named  function  type  input  and  output  is 
FN  B  *  ( enuml _to_enum2 : lhs)  ->  (enuml_to_enum2 :rhs) :  ... 


Where,  interna]  to  ‘B’,  ‘lhs’  is  a  value  delivering  function  type  which  is  made  up  of  a  value 
delivering  signal  of  type  ‘enum2’  and  a  value  requiring  signal  of  type  ‘enuml’.  Whilst  ‘rhs’ 
is  a  value  requiring  function  type  which  is  made  up  of  a  value  delivering  signal  of  type 
‘enuml’  and  a  value  requiring  signal  of  type  ‘enum2’  (see  [10]).  Hence  it  is  possible  to 
connect  the  input  signals  of  ‘B’  to  its  output  signals,  and  this  may  be  achieved  is  several 
ways.  For  example  via  an  OUTPUT  statement  e.g. 


FH  B  *  (enuml_to_enum2:lhs)  ->  (enuml. to_enum2 : rhs) :  H 

OUTPUT  10  lhs  H 

)-  I 


or  via  JOIN  statements  e.g. 


FH  B  *  (enuml _to_enum2 : lhs)  ->  (enuml. to_enum2 :rhs) : 

(  ... 

JOIN  lhs  ->  rhs, 
rhs  ->  lhs. 

)• 


or 
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FN  B  *  (•nual_to_«num2:lhs)  ->  (enuml_to_«num2:rhs) : 

(  ... 

JOIN  10  lhs  ->  10  rhs . 

). 


FI  B  ■  (•numl_to_«num2:lhs)  ->  (•nual_to_«num2:rhs) : 

(  ... 

JOIN  10  rhs  ->  10  lhs. 

). 


Function  types  can  now  be  used  anywhere  where  an  ordinary  type  is  used  providing 
it  is  meaningful.  Thus  replication  of  function  types  is  not  allowed  since  this  would  mean 
joining  an  input  to  a  signal  more  than  once.  The  syntax  of  function  types  is  given  in 
appendix  B.  For  a  complete  description  of  function  types  and  the  consequences  of  their 
extension  on  the  ELLA  language  the  reader  is  referred  to  [10]. 

5  Multiple  Instantiations 

In  ELLA  V4  it  was  only  possible  to  MAKE  either  a  single  instantiation  or  a  row  of 
instantiations  of  a  function,  for  example 


FN  FUNC  *  («iuml:in)  ->  «num2:  r*sl. 

FN  USE.FUNC  *  (•numl;in)  ->  •nua2: 

(  ... 

MAKE  FUNC:  «unc, 

[2] FUNC:  func2 . 


With  the  SPRITE-ELLA  system  it  is  possible  to  instantiate  rows  of  rows  of  functions  and 
the  number  of  rows  of  rows  that  can  be  instantiated  is  not  restricted.  Thus  it  is  possible 
to  say 


MAKE  [5] [3] [4] FUNC:  multfunc. 

and  the  type  of  ‘multfunc’  is  [5][3][4]enuml.to.enum2,  which  is  ‘a  row  of  row  of  row  of 
function  types’.  The  value  delivering  part  of  ‘multfunc’  is  then  of  type  [5][3][4]enum2,  and 
the  value  requiring  part  of  type  [5][3][4]enuml. 

In  ELLA  V4  it  was  necessary  to  supply  each  input  to  a  row  of  makes  separately.  Clearly 
for  the  case  of  multiple  rows  joining  each  element  separately  would  be  too  restrictive.  Thus 
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the  whole  question  of  joining  up  ELLA  circuits  has  been  considered  and  the  SPRITE-ELLA 
system  allows  inputs  to  multiple  rows  of  makes  to  be  supplied  all  at  once,  or  separately, 
or  in  groups.  The  next  section  describes  in  detail  the  enhancements  that  have  been  made 
to  ELLA’s  join  mechanism. 

6  Connectivity  Enhancements 

Earlier  versions  of  ELLA  only  allowed  a  single  identifier  after  the  *— ►’  of  a  JOIN 
statement,  possibly  followed  by  up  to  two  indices  (one  for  rows  of  makes  and  one  for 
function  set  rows).  This  form  of  ‘join  to’  structure  was  felt  to  be  too  limited  in  the  light 
of  the  function  type  work  and  multiple  makes.  Thus  the  structure  of  the  JOIN  statement 
has  been  enhanced  to  the  following  form 

JOIN  unit  — *  joinval. 

where 

joinval  joinvall 

joinval  CONC  joinvall 

joinvall  joinval2 

[INT  name  ■  intagar  . .  intagar]  joinvall 

joinval2  name 

10  name 

joinval2  [integer] 
joinval2  [integer  ..  integer] 

(  joinval  «,  joinval>>  ) 

with  the  ‘unit’  clause  remaining  unchanged,  and  <<,  joinval >>  representing  zero,  one  cr 
more  repetitions  of  “,  joinval”. 

A  JOIN  statement  takes  the  value  delivering  part  of  the  ‘unit’  and  connects  it  to  the 
value  requiring  part  of  the  ‘joinval’.  Only  in  the  particular  case  of  joining  IOidentifierl 
to  IOidentifier2,  where  both  identifierl  and  identified  are  function  types,  is  it  irrelevant 
which  way  round  the  JOIN  is  done  i.e.  IOidentifierl  — ►  IOidentifier2,  or  IOidentifier2  — ♦ 
IOidentifierl.  Examples  of  join  statements  are 

JOIN  aomathing  ->  (name  [3]  CONC  name  [2],  name [4],  namel  [2. .3] ) . 

JOIN  aomathingalsa  ->  [INT  k*2 . .5] (func_a[k] ,  func_b[k]). 

In  addition  to  supplying  extra  syntactic  constructs  the  JOIN  mechanism  has  been  extended 
to  allow  ‘complete  joins’,  and  ‘individual  joins’.  Complete  joins  allow  all  input  or  output 
signals  of  an  identifier  to  be  joined  in  one  statement.  Thus  multiple  makes  no  longer 
require  separate  JOIN  statements  for  each  row  e.g. 


SPRITE-ELLA 


Language  Enhancements 


FH  PART  ■  (tnunl:  in.  •nua2:  ip)  ->  («num2,  enuml):  (r«s2,  vail). 

FH  HULT.PART  «  (  [S]  [3]  [4]  (•muni ,  •nuntf^in)  ->  [5] [3] [4] (anum2,  «numl ) : 

(  HAKE  [5] [3] [4] PART: part. 

JOII  in  ->  part. 

OUTPUT  part 

). 

Individual  joins  are  in  a  sense  the  opposite  of  this  since  they  allow  identifiers  to  have  their 
signals  joined  one  at  a  time.  Thus  single  makes  which  used  to  require  all  their  inputs  to 
be  supplied  in  one  statement  can  now  have  them  spread  over  several  statements  e.g. 

FN  PART  *  (•muni:  in.  «num2:  ij.)  ->  (emun2.  anunl):  (r«s2,  vail). 

FN  USE_PART  «=  (*munl:in)  ->  ((«num2,  •numl) :out) : 

(  HAKE  PART: part. 

JOIN  in  ->  part[l], 
r«s2  ->  part [2], 
part[l]  ->  out[l], 
part  [2]  ->  out  [2]. 

)• 

Individual  joins  and  complete  joins  are  really  extremes  of  the  join  mechanism,  between 
them  there  is  a  variety  of  partial  joins  which  allow  signals  to  be  connected  in  different 
ways,  and  it  is  up  to  the  user  to  make  the  connection  decisions. 

6.1  Connectivity  Transformation  Example 

The  example  in  this  section  illustrates  how  a  circuit  using  the  new  connectivity  con¬ 
structs  can  be  transformed  into  a  circuit  which  would  be  valid  in  earlier  versions  of  ELLA. 
Consider  the  following  circuit 

TYPE  ty  ■  IEV  (tl|t2|t3) . 

FI  F  »  (ty:in)  ->  ty:  ... 

FH  G  *  (ty:in)  ->  ty:  ... 

FN  DEL  «  (ty)  ->ty:DELAY(?ty, 1) . 

FH  MAIH  *  (ty:in)  ->  (ty.out): 

(  HAKE  F:f , 

[5] DEL:  dal, 

G:g. 

JOIN  (in,  t  COIC  del,  g)  ->  (f,  del  COHC  g,  out). 

). 
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where  function  MAIN  merely  joins  its  input  to  some  function  F  then  delays  the  output  of 
F  through  five  unit  delays  before  passing  the  signal  into  function  G.  The  output  of  MAIN 
being  taken  as  the  output  of  G.  Transforming  the  function  MAIN  to  remove  the  extended 
joins,  and  hence  produce  a  function  which  would  be  valid  in  ELLA  V4,  gives 


FN  MAIN  ■  (ty:in)  ->  ty: 
(  MAKE  F:  f, 

[5] DEL:  dal, 

G:  g. 

JOIN  in  ->  f. 

JOIN  f  ->  dalfl] . 

JOIN  dal [1]  ->  dal [2]. 
JOIN  dal [2]  ->  dal [3]. 
JOIN  del [3]  ->  dal [4]. 
JOIN  del  [4]  ->  dal[S]. 
JOIN  dal [5]  ->  g. 
OUTPUT  g 

). 


It  can  be  noted  that  the  statements  with  connections  from  del[l]  to  del[4]  could  have  been 
put  into  a  multiple  join  statement  of  the  form 


FOR  INT  i  =  1..4  JOIN  del[i]  ->  del[i+l]. 


however  at  present  the  transformations  in  ELLA  replace  higher  level  constructs  with  lower 
level  ones. 

6.2  Regular  Array  Example 

In  this  example  a  basic  function  called  CELL  is  taken  and  combined  to  form  an  array 
of  cells.  Such  an  array  can  provide  the  basis  for  a  systolic  array.  This  example  makes 
use  of  the  extensions  to  the  MAKEs,  JOINs  and  function  types.  A  particular  example  is 
illustrated  in  figure  1. 
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Figure  1:  Array  with  m  =  3,  n  =  4 


TYPE  a  =  . . . 
b  -  .  . . 


INT  a  *  . .  • 
n  *  .  .  . 


FN  CELL  =  ((a->a):  xin,  (b->b):  yin)  ->  ((a->a):  xout,  (b->b):  yout): 
(  JOIN  (10  xin,  10  yin)  ->  (10  xout,  10  yout).  ). 


FN  ARRAY  «  ( [m] (a->a) :11, 
(  MAKE  [a] [n] CELL: call. 


[n] (b->b) : 12)  -> 

( [m] (a->a) :rl. 


[n] (b->b) :r2) : 


#  INTERNAL  JOINS  # 

FOR  INT  j  =  1 . .m-1  INT  i  =  l..n-l 

JOIN  (cell [j] [i] [1] .cell [j] [i]  [2] ) 

->  (cell[j]  [i+l]  [1]  ,cell[j+l]  [i]  [2]). 

FOR  INT  i  =  l..n-l  JOIN  cell[m] [i] [1]  ->  cell [m] [i+l]  [1] . 
FOR  INT  j  *  1 . .m-1  JOIN  cell [j] [n]  [2]  ->  cell [j+l] [n] [2] . 

*  EDGE  JOINS  # 

JOIN  1011  ->  [INT  j  «  1. .m] cell [j] [1] [1] , 

1012  ->  [INT  i  *  1. .n3cell[l] [i] [2] , 

[INT  j  «  1. .m]cell[j3 [n] [13  ->  IOrl. 

[INT  i  »  1. .n] cell [m3 [i] [2]  ->  I0r2. 

). 
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This  example  shows  how  partial  joins  can  be  used  to  connect  the  array.  However  the  joining 
of  the  cells  within  the  array  requires  several  statements.  By  redefining  the  specification  of 
CELL  the  internal  connections  of  array  can  be  made  more  succinct.  This  is  achieved  by 
defining  CELL  as  a  function-set  of  two  elements  i.e. 

FI  CELL.2  ■  ((a->a)->(a->a) :x,  (b->b)->(b->b) :y) :  (JOIN  x->x,  y->y.). 

where  ‘x’  describes  the  horizontal  information  and  4y’  the  vertical.  Then  the  function 
ARRAY  can  be  re-written  as 

FI  1KMY.2  *  (  [m]  (a->a)  :11 ,  [n]  (b->b)  :  12)  -> 

( [m] (a->a) :rl,  [n] (b->b) :r2) : 

(  MAKE  [m] [n] CELL. 2:  cell. 

LET  vert  -  [INT  j  -  l..jn][IHT  i  -  l..n]  10  cell[j]  [i]  [2]  , 

horiz  *  [INT  i  *  l..n][INT  j  “  l..nQ  10  cell[j]  [i]  [1]  . 

JOIN 

1011  CONC  horiz  ->  horiz  COIC  IOrl, 

1012  CONC  vert  ->  vert  CONC  I0r2. 

). 

where  ARRAY. 2  has  exactly  the  same  functionality  as  ARRAY  yet  its  internal  connectivity 
is  described  in  a  much  simpler  way.  A  complete  description  of  the  enhancements  to  the 
function  type/set  mechanism  for  describing  such  functions  as  CELL-2  can  be  found  in  [10], 

7  Timescaling 

The  timescaling  enhancements  for  ELLA  come  in  two  parts.  First  the  introduction  of  a 
new  language  primitive,  second,  the  introduction  of  hierarchic  time  regions.  The  language 
primitive  is  a  sample-and-hold  construct  which  will  allow  synchronous  descriptions  to  use 
ELLA  time  to  describe  clock  periods  other  than  one  per  time  tick.  The  hierarchic  approach 
will  allow  users  to  wrap  up  ELLA  functions  into  regions  which  operate  with  clock  periods 
either  faster  or  slower  than  the  surrounding  region.  These  two  features  are  related  by  a 
transformation  and  the  simulator  makes  use  of  this  fact. 

For  example,  a  hierarchically  faster  region  running  at  four  times  the  rate  of  the  outer 
region,  say,  would  be  transformed  into  a  region  which  has  its  inputs  held  constant  for  four 
time  units  and  its  output  sampled  ever  four  time  units.  The  outer  region  would  then  have 
its  delay  times  multiplied  by  four.  Thus  both  regions  would  appear  to  operate  within  the 
same  time  frame,  however  only  the  inner  region  would  change  each  time  unit  (the  outer 
region  effectively  changing  only  every  four  time  units).  Thus  users  have  at  their  disposal  a 
new  timing  primitive  which  can  be  accessed  either  explicitly  or  implicitly.  For  a  complete 
description  of  the  enhancements  and  the  implications  on  the  ELLA  system  the  reader  is 
referred  to  [5-8]. 
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7.1  Sample  Primitive 

The  new  sample-and-hold  primitive  occurs  in  the  same  syntactic  position  as  the  DELAY 
primitive,  that  is  it  is  the  sole  contents  of  a  function  body.  The  syntax  of  the  new  primitive 
is  of  the  form  [6] 

SAMPLE(interval  jize,  initial-value,  skew) 
or 


SAMPLE(interval-size) 

where  if  ommitted  ‘initial-value*  and  ‘skew’  default  to  ?type  and  zero,  respectively.  The 
‘skew*  value  determines  the  sample  point  and  its  value  must  be  less  than  the  interval-size. 

The  semantics  of  this  function  are  given  informally  as 

•  At  a  time  ‘t’  if  (t-skew)  is  some  multiple  of  the  interval  size  then  take  the  current 
input  value,  otherwise  the  output  remains  unchanged. 

A  formal  definition  of  the  semantics  of  SAMPLE  may  be  found  in  [8]. 

The  functionality  of  SAMPLE  may  be  demonstrated  by  considering  the  following  example 

TYPE  ty  -  HEW  (tl |t2 | t3 I t4 I t5 I t6 I t7 |t8 |un) . 

FH  SMP  =  (ty)  ->  ty:  SAMPLE(4,un,  2). 


In  this  case  SMP  samples  the  input  signal  every  4  units  with  the  sample  point  occurring 
after  2  units.  A  typical  simulation  run  then  gives  the  following  result 

TIME  :  0  1  23456789  10  11 

input  :  tl  t2  t3  t4  t5  t6  t7  t8  tl  t2  t3  t4 

output  :  un  un  t3  t3  t3  t3  t7  t7  t7  t7  t3  t3 

7.2  Hierarchical  Timing 

Hierarchical  timing  is  obtained  by  the  use  of  the  FASTER  and  SLOWER  constructs. 
Both  constructs  appear  in  the  same  syntactic  position  as  the  SAMPLE  primitive,  i.e.  the 
sole  contents  of  a  function  body,  and  they  instantiate  a  function  to  run  at  a  simulation 
rate  faster  or  slower  (respectively)  than  the  enclosing  region. 

The  syntax  for  the  FASTER  construct  is 

FASTER(function.name,  interval-size,  initial-value,  skew) 
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or 

FASTER(function.name,  interval-size) 

where,  ‘function-name’  is  the  name  of  the  function  which  is  to  have  its  clock  rate  set 
at  ‘interval .size’  times  faster  than  the  surrounding  region.  The  parameter  ‘initial-value’ 
determines  the  initial  output  value  of  the  faster  region  and  ‘skew’  sets  the  input  sample 
position,  if  omitted  ‘initial-value’  and  ‘skew’  default  to  ?type  and  zero  respectively.  A 
similar  syntax  follows  for  SLOWER  i.e. 

SLOWER(function_name,  interval-size,  initial.value,  skew) 

or 

SLOWER(function-name,  interval-size) 

again  if  omitted  ‘initial-value’  and  ‘skew’  default  to  ?type  and  zero  respectively.  The  re¬ 
striction  of  the  size  of  ‘skew’  for  FASTER  and  SLOWER  is  the  same  as  for  SAMPLE. 


7.3  An  Example  Transformation 

In  this  section  a  very  simple  circuit  is  shown  to  demonstrate  how  the  FASTER  and 
SLOWER  features  are  transformed  to  circuits  with  sample  primitives.  Consider  the  fol¬ 
lowing  ELLA  circuit  which  is  shown  in  figure  2. 


TYPE  a  *  HEW  (al|a2). 

FH  DEL  *  (a)  ->  a:DELAY(?a,2) . 

FH  F  *  (a: in)  ->  a:  DEL  in. 

FH  S  '  (a:in)  ->  a:  DEL  in. 

FH  FAST  «  (a)  ->  a:  FASTER(F,4,al,2) . 

FH  SLOW  «  (a)  ->  a:  SL0WER(S,3,a2,l) . 

FH  MAIH  =  (a: in)  ->  a:  DEL (SL0W(DEL (FAST  in))). 
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Figure  2:  Faster  and  Slower 


This  circuit  has  little  practical  use  and  is  given  merely  to  illustrate  the  transformation 
procedure.  The  functions  FAST  and  SLOW  are  transformed  to  remove  the  FASTER  and 
SLOWER  constructs  using  one  of  ELLAs  in-built  transformations.  The  resulting  circuit 
can  then  be  described  in  the  following  way. 

MAC  NEW_DEL{INT  period}  -  (a)  ->  a:  DELAY (?a,  period*2) . 

FN  F.SAMPLE  *  (a)  ->  a:  SAMPLE(4,  al,  2). 

FN  S.SAMPLE  =  (a)  ->  a:  SAMPLE(12,  a2,  4). 

FN  NEW.FAST  *  (a: in)  ->  a:  F_SAMPLE(NEW_DEL{l}in) . 

FN  NEW.SLOW  «  (a: in)  ->  a:  NEW_DEL{12}(S. SAMPLE  in). 

FN  NEW.MAIN  «  (a: in)  ->  a: 

NEW_DEL{4> (NEW.SLOW (NEW_DEL{4> (NEW.FAST  in) ) ) . 

The  functions  FAST  and  SLOW  have  now  been  transformed  so  that  they  have  a  SAMPLE 
function  at  the  end  and  beginning  of  their  respective  new  forms.  Because  SAMPLE  is  a 
core  primitive,  functions  F-SAMPLE  and  S.SAMPLE  are  needed  to  instantiate  particular 
instances.  It  can  be  seen  that  the  delays  external  to  the  timescaled  regions  have  also 
been  transformed.  If  function  NEW .MAIN  is  now  simulated  its  ‘clock’  will  be  that  of  the 
common  timebase. 

7.4  Retiming  Example 

In  this  section  we  apply  the  new  retiming  constructs  to  a  simple  ‘parallel  to  serial  to 
parallel’  circuit. 
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Consider  the  following  circuit  diagram. 


which  corresponds  to  the  following  ELLA  description 


TYPE  word  =  . . . 

MAC  INTERPOLATE  -  (  [INT  n] word : input )  ->  word: 

<  SEQ 

TYPE  intcount  *  NEW  ic/(l..n); 

FN  INC  *  (intcount: in)  ->  intcount: 

ARITH  IF  in  *  n  THEN  1  ELSE  in+1  FI; 
PVAR  count  ::■  ic/1; 

LET  out  =  input [[count]] ; 
count  : =  INC  count; 

OUTPUT  out 


MAC  DECIMATE  {INT  n}  ■  (word:nawvalua)  ->  [n]word: 

(  SEQ 

TYPE  intcount  ■  NEW  ic/(l..n); 

FN  INC  =  (intcount: in)  ->  intcount: 

ARITH  IF  in  *  n  THEN  1  ELSE  in+1  FI; 
PVAR  count  ::*  ic/1; 

PVAR  out  ::*  [n]zeroword; 

LET  pastout  =  out; 

out [ [count] ]  : *  nawvalue ; 

count  :■  INC  count; 

OUTPUT  pastout 

). 

FN  SCU  *  (word: input)  ->  word:  ... 
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FN  BLOCK  ■  ( [n] word: input)  ->  ft] word: 

(  LET  inter  «  INTERPOLATE  input. 

OUTPUT  DECIMATE  ft}  (SCU  inter) 

). 

FI  FASTBLOCK  -  (ft] word:  in)  ->  ft] word:  FASTER(BLOCK,  n) . 

where  the  body  of  function  ‘SCU’  has  been  left  unspecified,  this  function  represents  some 
form  of  Serial  Computation  Unit.  The  keyword  ‘FASTER’  in  the  function  FASTBLOCK 
signifies  entry  into  a  region  where  the  internal  clock  of  the  function  ‘BLOCK’  is  chang¬ 
ing  ‘n’  times  faster  than  the  outer  clock.  The  circuit  is  thus  modelling  a  parallel  to 
serial  (INTERPOLATE),  a  serial  computation  unit  (SCU),  and  a  serial  to  parallel  (DEC¬ 
IMATE)  function,  where  ‘n’  parallel  signals  are  transformed  into  ‘n’  sequential  signals 
which  then  pass  through  a  computation  unit  running  at  ‘n’  times  the  outer  rate,  before 
being  re-grouped  in  parallel.  This  circuit  follows  the  format  of  the  Silage  [2]  interpolate 
and  decimate  constructs. 

The  effect  of  the  faster  region  on  the  way  signals  are  handled  is  shown  in  the  following 
example  where  SCU  is  taken  as 

FN  SCU  ■  (word: input)  ->  word: input. 

Consider  the  case  where  n=4,  and  ‘word’  is  an  enumeration  type  defined  by 

TYPE  word  •  HEW  (al  I  a2  I  a3  I  a4  I  bl  I  b2  I  b3  I  b4  I  bn  ) . 

Then  simulating  the  function  ‘BLOCK’  with  the  input 

input  =  (al,  a2,  a3,  a4)  for  t  =  0..3 

input  *  (bl,  b2,  b3,  b4)  lor  t  *  4.. 7 

input  **  (bn,  bn,  bn,  bn)  lor  t  *  8 

gives  the  following  result 

TIME  BLOCK  inter  (internal  node  ol 

0  ?  ?  ?  ?  al  lunction  BLOCK) 

1  al  ?  ?  ?  a2 

2  al  a2  ?  ?  a3 

3  al  a2  a3  ?  a4 

4  al  a2  a3  a4  bl 

5  bl  a2  a3  a4  "b2 

6  bl  b2  a3  a4  b3 

7  bl  b2  b3  a4  b4 

8  bl  b2  b3  b4  bn 
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Simulating  the  function  FASTBLOCK  with  the  input 


input  =  (al,  a2,  a3 
input  *  (bl,  b2,  b3 
input  *  (bn,  bn,  bn 


a4) 

lor  t 

-  0 

b4) 

1  or  t 

•  1 

bn) 

lor  t 

■  2 

(i.*  t. inner  ■  0. .3) 
(i.e  t.inner  *  4.. 7) 


gives  the  following  result 


TIME 

0 

1 

2 


FASTBLOCK 
?  ?  ?  ? 

al  a2  a3  a4 

bl  b2  b3  b4 


The  results  show  that  FASTBLOCK  behaves  in  the  same  manner  as  BLOCK  however 
from  the  user  point  of  view  FASTBLOCK  only  requires  two  simulation  time  units.  In 
the  transformations  such  regions  of  hierarchical  timing  will  be  transformed  to  a  common 
time  frame  and  sample-and-hold  constructs  would  be  appropriately  placed  in  the  circuit. 
A  user  could  of  course  have  written  the  circuit  with  sample-and-hold  constructs  from  the 
outset,  however  the  use  of  the  hierarchical  timing  means  that  such  detail  can  be  hidden. 

8  Conclusions 

This  document  has  described  language  extensions  to  ELLA  that  have  been  carried 
out  for  the  SPRITE  project.  All  the  language  features  described  are  available  in  the  cur¬ 
rent  release  of  the  SPRITE-ELLA  system.  These  features  include  multiple  LETs,  multiple 
MAKES,  enriched  JOINs,  named  output  signals  and  the  inclusion  of  timescaled  regions.  In 
addition  to  this  SPRITE  also  has  access  to  the  enhancements  of  the  function  type  mecha¬ 
nism  carried  out  under  the  IED  (Information  Engineering  Directorate)  ELLA  Behavioural 
Synthesis  project. 
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A  Syntax  of  Multiple  Declaration 

The  full  ELLA  syntax  will  not  be  described  in  this  appendix,  only  those  parts  which  have 
changed  as  a  result  of  the  work  detailed  in  this  document  are  given.  For  a  complete  de¬ 
scription  of  the  syntax  the  reader  is  referred  to  the  ELLA  language  reference  manual  [3]. 

In  this  appendix  the  following  convention  and  notation  will  be  adopted 


<<  statements  >>  •*  zero,  one  or  more  ‘statements' 


name  **  a  let,  make  or  function  terminal  name 

declaration  »»  a  TYPE,  1HT,  CONST ,  FN  or  MAC  declaration 
printitem  ■■  a  set  of  output  strings  or  names 

faultitem  ==  a  set  of  output  strings  or  names 

unit  **  a  value  delivering  ELLA  clause 

nullname  ■=  a  blank  character 

integer  **=  a  non-tagged  integer 

value  ■■  an  ELLA  CONSTant  value 

step  ■«  a  step  in  a  BEGIN  . . .  END  clause 

sequencestep  **  a  step  in  a  BEGIN  SEQ  . . .  END  clause 

seqchoice  «  Sequential  CASE  chooser  with  value  delivering  clause 


A.l  Syntax 

applicative  statements: 


step 


letitem 


LET  letitem  <<,  letitem>> 
declaration 

MAKE  makeitem  <<,  makeitem>> 

<<  FOR  multiplier  >>  JOIN  joinitem  <<,  joinitem>> 
PRINT  printitem  <<,  printitem>> 

FAULT  faultitem  <<,  faultitem>> 

nameslist  •  unit 


nameslist  name 

(  nameornull,  naaeornull  <<  ,  nameornull>>  ) 

nameornull  : -  name 

nullname 


sequential  statements: 


sequencestep  LET  letitem  <<,  letitem>> 
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VAR  varitem  «,  varitems 

STATE  VAR  statevaritem  «,  statevaritemS 

PVAR  pvaritem  «,  pvaritemS 

statement 

declaration 

PRUT  printitem  «,  printitea>> 

FAULT  fault  it  ea  «,  fault  it  en>> 

varitem  nameslist  :■  unit 

statevaritea  nameslist  IHIT  values 

pvaritem  : -  nameslist  : : *  values 

statement  varnameslist  :*  unit 

(  <<stateaent; >>  statement  ) 

[INT  name  =  integer. .integer]  statement 
IF  boolean  THEN  statement  FI 
IF  boolean  THEN  statement  ELSE  statement  FI 
CASE  unit  OF  seqchoice  <<ELSE0F  statements  ESAC 
CASE  unit  OF  seqchoice  <<ELSE0F  statements 

ELSE  statement  ESAC 

varnameslist  : -  varname 

(  varnameornull  ,  varnameornull  <<,  varnameornull  >>  ) 

varnameornull  : -  varname 
nullname 

varname  : -  name 

varname [integer] 
varname [ [unit] ] 
varname [integer. . integer] 

values  : -  value 

(  value,  value  <<,  value  >>) 

A. 2  Semantics 

The  following  two  types  of  multiple  statements  are  not  allowed  semantically 

i)  LET  (a,  b,  c)  «  STRUG  [3]bit’0. 
ii)  (array[l],  array[2],  array[l])  :■  THREE.CUT.FUBC(input) ; 
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In  i)  a  STRING  and  a  structure  are  considered  to  be  different  objects  and  so  such  an 
equality  cannot  be  made.  This  approach  is  consistent  with  that  adopted  for  the  REFORM 
operator. 

In  ii)  the  ordering  of  the  left  hand  side  assignments  cannot  be  assumed  as  they  are  treated 
as  parallel  statements  within  the  assignment  statement.  Thus  the  result  of  this  statement 
is  undefined.  A  restriction  was  therefore  placed  on  such  assignment  statements  not  to 
allow  the  same  identifier  more  than  once  on  the  left  hand  side.  In  some  cases  this  would 
be  too  strong  a  restriction,  for  example 


(array [1] ,  array [2])  :■  TMO.OUT_FUHC(input) ; 

However  to  avoid  any  potential  ambiguity  that  could  arise  the  compiler  implements  the 
stronger  restriction.  Of  course  such  statements,  as  shown  above,  can  always  be  written 
without  the  use  of  such  assignment  statements. 
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B  Syntax  of  Function  Types,  Makes  and  Joins 

The  full  ELLA  syntax  will  not  be  described  in  this  appendix,  only  those  parts  which  have 
changed  as  a  result  of  the  work  detailed  in  this  document  are  given.  For  a  complete  de¬ 
scription  of  the  syntax  the  reader  is  referred  to  the  ELLA  language  reference  manual  [3]. 

In  this  appendix  the  following  convention  and  notation  will  be  adopted 


statements 

K 

N 

A 

A 

zero,  one  or  more  ‘statements’ 

name 

MM 

a  let,  make  or  function  terminal  name 

fnname 

mm 

an  upper  case  function  name 

type 

mm 

any  ELLA  type 

fntype 

mm 

an  ELLA  function  type 

unit 

cs 

a  value  delivering  ELLA  clause 

integer 

SB 

a  non-tagged  integer 

B.l  Type 

type  :  -  name 

[integer] type 
(type  <<,  type>>) 
fntype 

fntype  type  ->  type 


B.2  Function  Specification 

FN  fnname  =  input  ->  output:  #  An  ordinary  ELLA  function  # 

FH  fnname  *  fnsetspec:  #  An  ELLA  function  set  # 

input  :  -  ( ) 

(decs  <<,  decs>>) 

output  : -  type 

() 

(decs  «,  decs>>) 

decs  : -  type  :names 

type 

names  :-  name  <<name>> 

fnsetspec  :-  (  fntypespecs  <<,  fntypespecs>>  ) 


25 


SPRJTE-ELLA 


Language  Enhancements 


fntypespecs  : -  Jnsetdecs  :  names 
fnsetdecs 

fnsetdecs  [integer]  fnsetdecs 

(  fnsatdacB  «,  fnsetdecs>>  ) 
fntype 

SEMANTIC  NOTES  ON  FUNCTION  SPECIFICATION 

In  a  function  set  the  ‘fntype’  can  be  a  structure  of  function  types,  or  rows  of  function 
types  or  a  combination  of  the  two.  Unlike  previous  versions  of  ELLA  there  is  no  restriction 
on  the  sort  of  components  a  function  set  structure  may  have.  Also  function  sets  do  not 
now  need  to  be  explicitly  ‘MADE’  before  they  are  used. 

The  input /output  type  given  as  *()’  is  a  ‘void-type’  which  indicates  that  there  is  no 
input /output  terminal  present.  At  present  ‘void-type’  can  only  appear  in  a  function  spec¬ 
ification  as  shown  or  as  the  input  to  an  implicit  function  call  or  as  the  sole  contents  of  an 
‘OUTPUT’  clause.  Extensions  of  the  use  of  ‘void-type’  are  being  considered. 


B.3  Multiple  Makes 

makeitem  << [integer] >>  fnname  :  names 


B.4  Partial  Joins 


joinitem 

unit  ->  joinval 

joinval 

joinvall 

joinval  COHC  joinvall 

joinvall 

joinval2 

[IHT  name  *  integer  . .  integer]  joinvall 

joinval2 

:  -  name 

10  name 

joinval2  [integer] 
joinval2  [integer  . .  integer] 

(  joinval  <<,  joinval>>  ) 
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C  Syntax  of  Timescaling 

The  full  ELLA  syntax  will  not  be  described  in  this  appendix,  only  those  parts  which  have 
been  added  as  a  result  of  the  timescaling  are  given. 

In  this  appendix  the  following  convention  and  notation  will  be  adopted 


fnspec 
Inn am* 
int*g*r 
constant 


an  ELLA  function  specification 
an  upp*r  cas*  function  nam* 
a  non-tagg*d  int*g*r 
an  ELLA  constant 


C.l  Sample 

FN  fnname  *  fnspec:  body.  #  An  ELLA  function  # 

body  SAMPLE (integer,  constant,  integer) 

SAMPLE ( integer ) 


where  in  the  case  of  no  constant  or  second  integer  being  supplied  they  take  the  default 
values  of  unknown  type  and  zero.  If  a  second  integer  is  present  then  its  value  must  be 
between  +  or  -  the  value  of  the  first  integer. 

C.2  Faster  and  Slower 


FB  fnname  ■  fnspec:  body. 


#  An  ELLA  function  # 


body 


FASTER(fnname,  integer, 
FASTER (fnname,  integer) 
SLOWER(fnname,  integer, 
SLOWER(fnname,  integer) 


constant, 

constant, 


integer) 

integer) 


where  in  the  case  of  no  constant  or  second  integer  being  supplied  they  take  the  default 
values  of  unknown  type  and  zero.  If  a  second  integer  is  present  then  its  value  must  be 
between  +  or  -  the  value  of  the  first  integer. 
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